\section{nvSRAM backup flow}
%\Note{Introduce the main principle of our backup flow: explained by equations}
%\Note{Give the overall backup flow, compared with conventional backup flow}
To mitigate the problems addressed in section~\ref{motivation}, we concentrate on systematic level backup flow optimization for nvSRAM. Theory basis and the overall backup flow are discussed in this section.

\begin{figure}[!hpt]
\centering
\subfigure[Conventional backup flow]{\label{bflowa}\includegraphics[scale = 0.6]{bflowa.pdf}}
\subfigure[Proposed backup flow]{\label{bflowb}\includegraphics[scale = 0.6]{bflowb.pdf}}
\caption{Comparison of backup flows}\label{bflow}
\end{figure}

Fig.~\ref{bflow} shows the comparison between the conventional backup flow and our proposed backup flow for nvSRAM. In the conventional backup flow, full backup is carried out after power off and then the nvSRAM is moved into the off-state. Our proposed backup flow is consisted of two processes: a partial backup process (on the right side of fig.~\ref{bflowb}) and a run-time pre-writeback process (on the left side of fig.~\ref{bflowb}). Steps that marked by red edges represent that they are powered by the energy storage capacitor.

When external power is cut off, the nvSRAM starts a partial backup process. The partial backup process aims to reduce the backup redundancy in block level by discarding useless block data, denoted as dead blocks. Therefore, the first step is to predict dead blocks. This process adopts the SBDP scheme. The details of SBDP will be discussed in section~\ref{}. The second step leverages the dead-block information and carries out the partial backup process and finally moves nvSRAM into the off-state after backup completed.

Nevertheless, we notice that the patrial backup scheme introduces high overflow rates for some applications. An overflow occurs when the required backup energy exceeds the energy budget supplied by the energy storage capacitor. In that case, the system state can not be stored correctly, so the system states can only roll back to the last backup point. To mitigate the problem, a run time self-adaptive pre-writeback process is included in our back flow. A backup warning signal is generated if a possible overflow is detected. Then, the backup controller first checks the backup history and makes the pre-writeback decision based on the power-off frequency. Details will be discussed in section~\ref{}.

